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System and method for searching, finding and contacting dates on the 
Internet in instant messaging networks and/or in other methods that 
enable immediate finding and creating immediate contact. 

Background of the invention 

Field of the invention: 

The present invention relates to instant messaging and computer dating on 
the Internet, and more specifically to a system and method for computer dating 
in the context of instant messaging, and/or in other methods that enable 
immediate finding of potential dates and creating immediate contact. 

Background 

Computer dating means matching people by computer after filling a 
questionnaire which typically contains a description of a list of attributes in 
themselves and a list of attributes that they want in their ideal date. Such 
services have existed on the Internet for a number of years. 

Instant messaging is a relatively new technology that has existed for about 4 
years, in which people are able to find instantly if any individuals in a specified 
list of friends or acquaintances are logged in to the Internet at a given time and, 
if so, communicate with them instantly. This technology is typically based on 
the principle of the client program sending a very short message (with the user's 
unique id number in the instant messaging network) at relatively short intervals 
(such as for example once a minute) to a central servers or servers whenever the 
user is logged- in to the Internet and the client program is. activated. This way, 
when these messages cease, the server(s) knows that the user is no longer 
connected, even if he did not terminate the connection properly. When users 
know that they are online at the same time, they can start exchanging instant 
messages or open realtime textual online chat. The 3 most known instant 
messaging networks on the Internet today are ICQ, AOL's Instant Messenger, 
and Microsoft's MSN Messenger. 

However, when searching for new people, the current instant messaging 
networks typically allow users to search mainly by name or by e-mail and some 
of them also by interests, although one of them (Odigo) allows to search also by 
sex, age, area, languages, occupation & interests. However, to the best of my 
knowledge there is no way to systematically search in these networks for 
compatible dates by attributes such as education, general background, 
appearance, attitudes, and personality, or by reciprocal compatibility in any of 
the above mentioned attributes. This is a waste of a huge potential since some 
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of these networks already have more than dozens of millions of people. Also, 
Odigo allows searching only among people currently connected, which means 
that highly compatible dates can be missed just because they don't happen to be 
connected at exactly the time of the search. Also, Odigo does not show people 
by order of compatibility. Adding such features to instant messaging systems 
would be a significant improvement over the prior art in instant messaging 
systems and in computer dating systems. 

This ability for instant contact is important also because one of the things that 
are missing in online computer-dating systems is the possibility to have a 
systematic search for reciprocally compatible dates, and then to be able to 
contact immediately the compatible dates, such as for example by getting their 
phone number or being able to instantly communicate with them through the 
Internet. Typically computer dating systems give usually only the e-mail 
address of compatible dates, or even worse - allow only to leave them a 
message in a special mailbox within the computer-dating system. This can be 

: very bad because if a normal e-mail is not generated it can take a long and 

C- frustrating time to get a response. 

Ill 

yj The only relevant patent that I saw is US patent number 5,963,951 by Gregg 

i|i Collins, granted Oct. 5, 1999. However, my opinion is that almost everything in 

== that patent is either trivial or exists already in prior art. And yet he got the 

patent. The Present invention is much more sophisticated and with much more 
1^ advance over the prior art. 

H 

P Summary of the invention 

ru 

The present invention is a novel concept which applies computer dating to the 
context of instant messaging, in a systematic and flexible way that to the best of 
the inventor's knowledge has never been done before. This system and method 
enable the user to search and find instantly compatible dates in instant 
messaging networks on the basis of attribute search or 1-way compatibility 
search or 2- way compatibility search instead of being limited to search only by 
the limited options described above, and to search either for potential dates that 
are currently Online or Offline, and also take advantage of many additional 
features, and especially features that are based on improved integration between 
computer dating and instant messaging. A further feature of the present 
invention is that preferably at least in one embodiment it can work also across 
instant messaging networks, so that users can find each other even if they are 
members in different instant messaging networks. A further feature of this 
invention is that it can make the large instant messaging networks also the 
biggest dating services in the world. It can also help them start charging for 
payments in the future, after a sufficient number of users have also started using 
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the dating option. It can help them grow even faster for example by increasing 
further the users' motivation to recommend the system to additional friends. 
(For example by giving the user more privileges, such as additional lists or 
credits points for each friend that they bring). It might also be extended 
similarly to cover also chat networks such as for example IRC (for example by 
coupling an appropriate add-on to the IRC client). 

The system and method are preferably based at least on two main elements: 

1 . A module (or modules) for filling and making changes to the computer 
dating questionnaire, preferably containing self-description, description 
of the ideal date, and the importance for each question. This module can 
be implemented preferably as either: 

a. An appropriate plug-in or add-on or element in a plug-in or add-on 
for the client program preferably for each of the main instant 
messaging networks where plug-ins or add-ons are possible, 

b. A standalone application or part of a custom-made instant 
messaging client. 

The data filled by the user is then preferably either saved locally on 
his/her computer, or sent to a central server (or servers), or both. 

2. A search & instant messaging contact module or modules for finding & 
contacting potential dates (For example by attribute search or reciprocal 
compatibility search) who are currently Online and/or who can be added 
to a contactee list in order to notify the user when they are Online again. 
Preferably, this module can be either based on: 

a. A suitable plug-in or add-on coupled to the client program 
preferably for each of the main instant messaging networks where 
plug-ins or add-ons are possible, that is activated each time the 
user activates said client program. Whenever this plug-in or add-on 
is activated, preferably it first sends the user's compatibility 
questionnaire data to a central server (or servers) (this is needed for 
example in case the database of potential dates is dynamic and 
exists only during the time that these people are logged in, or if the 
user has just filled the questionnaire for the first time or made 
changes to it) and then sends only small packets of data containing 
at least the user's unique id every certain interval. (Taking care of 
sending these short messages may be done also by a separate 
element or plug-in or add-on). When the user wants to search for 
new people to add to his contact list for example according to 
attributes search or 2-way compatibility search, preferably the 
search is done either on the dynamic database as explained above 
or in a static database of users that filled the compatibility 
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questionnaire, according to different embodiments. The system can 
(preferably in different embodiments, or as options in one 
program) use either a static database or a dynamic one, or both - 
for different types of searches and for efficiency considerations. 
However, even if a dynamic database is used, at least minimal data 
such as the user's name and e-mail and unique ID, is preferably 
kept also in a central static database on the server. If the search is 
done on the dynamic database (or on a static database with a 
request to ignore all those who are not currently Online), the 
people found are already by definition only people that are 
currently logged on. If the search is done on a static database of 
people that filled the questionnaire without the requirement that 
they be currently online, preferably the user can either: 

1 . Add them to the contact list on his normal instant messaging 
l rs = client program, and then the user will be notified by the 
"j instant messaging client itself whenever they are logged in. 

J However, if some of these persons are members of other 

instant messaging networks, the user will need to ask them 
ry to join also the network in which he/she is enlisted, 

Mj otherwise he/she will not be able to add them in this way. 

2. Add them to a special contact list maintained by the plug-in 
a or add-on itself, and then the user will be notified by the 
Ci plug-in or add-on whenever they are logged in. This second 
M= option is better of course, because it enables the user to be 
=■ notified also if the target people are members in instant 
-f messaging networks other than the one the user belongs to. 

However, in this case the plug-in or add-on preferably also 
includes an element that enables the User to communicate 
and exchange instant messages with users of other instant 
messaging networks, unless the user asks them to join also 
his/her own network. Preferably, the plug-in or add-on does 
this for example by using the same protocol for instant 
message exchange between plug-ins or add-ons in all types 
of clients for which we design a plug-in or add-ons. Another 
possible implementation of this feature is that if the add-on 
is based at least in part on a wrapper around the client or is 
more fully integrated with the client, it can for example let 
the client or part of the client act as if it is communicating 
with another client of the same network or with its server, 
but translate the communication to another protocol and/or 
redirect it, as shown in Fig. 7. This has the advantage of 
letting the user continue working with the interface and 
front-end that he/she is used to in his/her favorite IM 
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network. Preferably the system knows if someone is Online 
either by contacting the appropriate server of the IM 
network to which the client belongs, or, preferably in a 
different embodiment, by using our own server and 
generating our own repeating signal from the client. This is 
no problem, since in order to participate in the dating, all 
users of the system on other IM networks are using an 
appropriate plug-in or add-on anyway, so they all can 
connect to the same server and use the same protocol for the 
repeating signal. 
Both if the search was only for people currently online or 
also people offline, preferably the user can similarly add any of 
the people that came up in the search to his/her list of contactees 
in any of the ways explained above - so that he/she can be 
automatically notified when they are Online again the next time 
(Preferably the user may for example click on them one by one or 
mark a whole group for adding). 

b. A complete or independent instant messaging application that 
works like a normal instant messaging client connecting to a main 
server or servers, with the added features of being able to search 
for users for example by attributes or by 1-way or 2-way 
compatibility. Preferably, the system can also similarly use either a 
static database or a dynamic one, or_preferably both - for different 
types of searches and for efficiency considerations (preferably in 
different embodiments), and have features as described above. 
However, even if a dynamic database is used, at least minimal data 
such as the user's name and e-mail and unique ID, is preferably 
kept also in a central static database on the server. This complete 
application can be either a stand-alone, or a plug-in or add-on 
coupled to a major Internet communication program, such as one 
of the big browsers, or for example an integral part of the browser, 
so that for example the IM client (or at least part of it) and/or the 
part of the client that deals with dating are integral parts of the 
browser. 



Definitions and clarification 

Through out the patent whenever possible variations are mentioned, it is also 
possible to use combinations of these variations. These variations can be in 
different embodiments, or different version of the software, or sometimes 
different options available to choose from. 
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As used throughout the present specifications and the claims, the following 
words have the indicated meanings: 

"Client" or "Client program" is an application that runs on the user's computer 
and communicates with a server or servers, usually on the Internet. In the 
context of this invention, Client means Instant Messaging Client, unless stated 
otherwise. 

"Server" or "Servers" as used throughout the patent, including the claims, are 
always meant interchangeably to be either server or servers. "Server" is a 
computer on a network that is running software (or the software itself) that 
provides data and services to clients over the network (which can be any kind of 
network, including the Internet). 

"Our client" or "Our own client" refers to a custom-made instant-messaging 
client with the features of this invention built-in. 

"Our server" or "Our own server" refers to a custom-made instant-messaging 
server with the features of this invention built-in. 

"Standalone" is an application that runs on it's own. 

"Plug-in" is an application that runs as part of or as an addition to another 
application and is called from it when needed. "Add-on" is a more general term 
than plug-in and refers to elements or features that are added to or coupled to a 
given application in any way possible, such as a plug-in or with a program that 
wraps around it, or in any other way allowed by the application or by the 
operating system. As used throughout the text of the patent, including the 
claims, these terms are meant to be interchangeably either plug-in or add-on. 

"Plug-in" or "Plug-ins" as used throughout the patent, including the claims, are 
always meant interchangeably to be either Plug-in or Plug-ins 

"Add-on" or "Add-ons" as used throughout the patent, including the claims, are 
always meant interchangeably to be either add-on or add-ons. 

"User" or "users" as used throughout the patent, including the claims, can 
interchangeably to be either user or users. 

"Dynamic Database" as used throughout the text, including the claims, means 
that the data from the users questionnaires is kept on the server or servers only 
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as long as they are Online, so when a user becomes Online again his/her data is 
resent from his/her client program to the server. 

"Static Database" as used throughout the text, including the claims, means that 
the data from the users questionnaires is kept on the server or servers also when 
they are not Online, and preferably their Online/ Offline status is kept as part of 
their records or in a separate file or pointer or index. Of course 'static' does not 
mean that the data in the database doesn't change - data can be updated as often 
as needed. 

"Database" or "Databases" or "DB" as used throughout the patent, including 
the claims, are always meant interchangeably to be either database or databases. 

"Contactee list" or "Contact list" or "Buddy list" refers to the list of people for 
which the user wishes to be notified when they are Online. 

"History list" in instant messaging systems is the list of previous messages 
exchanged between the user and a given contactee. 

"IM" is short for Instant Messaging. 

"Cellular phone" or "mobile phone" or "wireless phone" as used throughout the 
patent, including the claims, can mean any device for communications through 
wireless and/or cellular technology, including for example Internet-enabled 
cellular phones, such as the Japanese DoCoMo, 3 rd Generation cellular 
communication devices, palm computers communicating by cellular and/or 
wireless technology, etc. 

"Computer" as used throughout the text of the patent, including the claims, can 
refer to a personal computer, or any automated device or gadget with one or 
more processor or CPU, capable of more than simple arithmetic functions. This 
includes for example also cellular phones and portable computing devices such 
as palm pilot. 

"Online" or "logged-on" or "logged-in" as used throughout the text of the 
patent, including the claims, in the context of IM networks means that a user is 
connected to the Internet, with the IM client open, unless for example the 
contact has been open for a long time and the user hasn't typed anything (or 
clicked or responded or shown any other type of activity). In the context of 
Online Computer Dating Services it means that the user has logged into the 
system for example with his/her user name and password not longer than a 
certain time ago (for example within the last 20 minutes or any other reasonable 
time frame), and/or the user has performed at least one activity in the system 
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(such as for example view data, change data, or perform a search for compatible 
dates) not longer than a certain short time ago. 

"Internet" is the Internet as it is now, or any other similar network that exists or 
will exist in the future. 

"Self Description" or "Self data" throughout the text, including the claims, 
means the answers the user gives about himself/herself in the Dating 
Questionnaire. Except for some special questions, the user can preferably 
choose just one answer in each question for his/her self-description. For 
example, the user marks that he has dark hair in the question about hair color. 

"Desired date", "Ideal date", "Preferences" or "Wanted" throughout the text, 
including the claims, mean the answers the user gives about the optimal and 
acceptable levels he/she wants to have in the desired date in each question. 
Preferably, the user can choose more than one option in the "wanted", and 
preferably also specify the level of desirability of each option that he/she 
prefers. For example in hair color the user wants Blonde girls with higher 
desirability and red hair with lower desirability. 

"Importance" or Weight" means the level of importance the user gives each 
question, for example: Doesn't matter, Slightly important, Important, Very 
important, Extremely important, or Necessary. 

"2-way compatibility" means that the matching is done by taking into account 
both the user's self description and preferences and each potential date's self 
description and preferences, and preferably also the importance given by each 
of them to each of the questions. 

"1-way compatibility" means that the matching is done at least by taking into 
account the user's preferences and each potential date's self description and 
preferably also the importance the user gave to each question. However, 
preferably even when conducting 1-way search, the system actually does a 2- 
way search, in order to check that the user also fulfills the potential date's 
expectations by at least a certain minimum, preferably defined by the system. 
Since the dating questionnaire is preferably long, containing for example above 
100 questions, preferably when conducting 1-way or 2-way searches the data is 
used directly from the saved questionnaire. 

"Attribute search" means that the user just marks a certain preferably small 
number of attributes that he/she wants to search for in the potential dates. The 
importances for this small set of preferences can be for example assumed to be 
necessary, or in another possible embodiment the user can specify the 
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importances even in this case. Preferably this fast search is either conducted by 
ignoring the user's self description, or conducted similarly to the 1-way search 
described above, except that the attributes are preferably defined by the user on 
the fly and used instead of his/her full list of preferences. Preferably, the results 
of the attribute search can be for example just dates that fulfill a 100% of the 
requests or any percent above the defined minimum like in the 1-way and 2- 
way searches. 

"Frozen" means that a certain user does not receive compatible dates lists and 
does not appear on other users' lists until the user requests to be unfrozen or the 
system decides that a certain event has occurred that justifies unfreezing 
him/her (for example if the user has reentered the system after being Offline 
for a long time and the freezing was done automatically by the system due to 
lack of activity and not due to a specific request by the user). 

Brief description of the drawings 

Fig. la shows a preferable structure of the client-server system in the instant 
messaging network, with the part that implements the dating. 

Fig. 1 is a schematic diagram of a preferable way the questionnaire-filling 
application works as a plug-in or add-on within an instant-messaging client. 

Fig. 2 is a schematic diagram of a preferable way the questionnaire-filling 
application works as a standalone application or as part of a custom-made 
instant messaging client. 

Fig. 3 is a schematic diagram of a preferable way that a dynamic database of 
users that are currently Online works. 

Fig. 4 is a schematic diagram of a preferable way that a static database of users 
that filled the compatibility questionnaire works. 

Fig. 5 is a schematic diagram of a preferable way the search plug-in or add-on 
conducts attribute and compatibility searches within the context of the instant 
messaging client. 

Fig. 6 is a schematic diagram of a preferable way attribute and compatibility 
searches are conducted within a custom-made instant messaging client. 

Fig. 7 is a schematic diagram of a preferable way that the add-on can for 
example let the client or part of the client act as if it is communicating with 
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another client of the same network or with its server, but translate the 
communication to another protocol and/or redirect it to the other network. 

Fig. 8 is an example of a preferable way that the extended contactee list can 
look like. 

Fig. 9 is an example of a preferable way that the list of most compatible dates 
following a reciprocal compatibility search can look like. 

Detailed description of the preferred embodiments 

All of descriptions in this and other sections are intended to be illustrative 
examples and not limiting. The system and method described may be also 
regarded as a virtual machine that performs the described functions. 

Fig. la shows a preferable structure of the client-server system in the IM 
network, with the part that implements the dating. The instant messaging client 
(2) runs within the user's computer (1), and, if it's not a custom-made client, is 
preferably coupled to a plug-in or plug-ins or add-on or add-ons (3) for adding 
the special features of the current invention, otherwise the parts that implement 
these features in the client are part of the client itself. The user's computer (1) is 
connected through connection (4) to the Internet (5), where our server(s) (6) 
(with dynamic or static database(s) or both (7)) reside. The database (no matter 
if dynamic or static) is of course preferably run by the server, and all date 
searches are preferably carried out there, although there can be for example a 
separation between the server (or servers) that handles the IM activity, and 
another server (or servers) that run the actual dating database and perform the 
searches and compatibility matches, etc., and return the results to the requesting 
client programs. 

Preferably the system also has at least one or more of the following 
improvements over existing Instant Messaging systems: 

1. The contactee list is preferably run by the client program (2) in the 
customary shape of a table, but preferably indicates also near each 
contactee additional data such as for example the last date & time he/she 
was online (in the instant messaging network) and/or the most common 
range of hours and/or week days he/she is most likely to be found online 
(In another variation this can be a more crude time range, such as for 
example, morning, noon, afternoon, early evening, late evening, and 
night), and/or for example the last time he/she performed a search for 
potential dates in the system (preferably the client program automatically 
gets these updates from the server when the user is Online), and/or 
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geographical area (or for example some relative distance estimate 
compared to the user), and/or the compatibility scores, and/or how often 
they are usually online (such as for example how many hours on average 
per week or per day). This is very important since many times, and 
especially if the user has not used the system for some time, it is very 
hard to tell which of your contactees are still available and when it is 
likely to encounter them. Preferably near each contactee is listed also the 
last time contact was made with him/her and/or for example the length of 
his/her history list. Preferably, the table of contactees contains also a 
visible status indication about each person - for example if he/she is still 
looking for romance or other types of connection, etc. Preferably these 
additional data fields are visible by default near each contactee without 
having to click on anything in order to see them. An example of a way 
the contactee list can look like is shown in Fig. 8. 

2. Preferably the user can choose if to sort the contactee list according to 
alphabetic order, compatibility score (at least for those contactees that 
were added through the date-searching), or any of the other data 
mentioned in clause 1 above or additional data , or any combinations of 
these. 

3. Preferably the user has the ability to know how many people have 
him/her in their contactee lists. This is very easy to accomplish since 
either the user's client program or the server or both can for example 
increase a counter or decrease it whenever someone adds or deletes the 
user. Another possible variation is that the client program or the server or 
both can also keep a list of all the people that added the user to their 
contactee lists, so that the user can for example send messages that can be 
automatically distributed to all of them, and/or request to view the list of 
people that have him/her on their lists (preferably at least their names and 
e-mails and/or IM ids). So preferably the server and/or the client program 
keep for each user also a "reverse" contactee-list, which lists all the other 
users who added him/her to their list and haven't deleted him/her yet. 
Another possible variation is that the server keeps only a copy of each 
contactee list and when needed the server runs over these lists and 
searches them, preferably with the aid of an index. Of course, if the act of 
adding someone to the list of contactees is reciprocal, then the client 
program can know automatically that you were also added to their list, 
but this is not necessarily so, especially in cases that the person has not 
limited adding him to the list to requesting explicit authorization. Also, 
even if the adding to the contactee list could in some systems be 
automatically reciprocal, there is no reason why the deletion should be 
like this: if person A deletes person B from his list, it does not 
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necessarily mean that person B wants to delete person A from his list, so 
the deletion process would make it non-trivial to know on which or on 
how many contactee lists you are actually listed. 

4. Preferably, if someone changes his/her status for example from 
"available for dating" to non-available, etc., this is automatically 
broadcast (for example by the client program of that user or by the 
server) to all the people who have him/her on their contactee list, so that 
his/her status is updated on their lists (This can be done for example by 
an automatic message directly from that user's client program that 
updates the client programs of these people when they are Online and if 
they are Offline waits for them till they are Online again, or for example 
done similarly through the server). This updating is' of course preferably 
in addition to making the person not appear in further date searches by 
others if the change in status implied this (until the status allows this 
again) - for example if he/she is in a relationship, etc. 

5. Preferably when the matching potential dates are found, they are listed by 
descending reciprocal compatibility score. However, since there can be a 
large variance between the way people mark the acceptable ranges in the 
"Wanted" in each question and the way they mark the importances of 
questions, the score of how much someone fits the user's expectations 
can depend very much on the general bias of the user, in other words 
his/her tendency to be more or less "generous" in general in his/her 
scores. Therefore, in order to create a certain minimum normalization, 
preferably for sorting by reciprocal score, the score of how much the 
potential date fits the user's expectations is preferably given stronger 
weight (and thus effects more the reciprocal score, which is a weighted 
average) than how much the user fits the potential date's expectations. 
Another possible variation is to create some normalization of this by 
taking into account for example the average 1-way score that the user 
gives compatible dates and his standard deviation, and thus either use 
normalized scores, or use the normalization to create only a partial 
correction of the absolute scores. This is more preferable than full 
normalization because the fact that someone gives generally higher 
scores to everyone can also mean that he/she is really more open and 
more fit for many people than someone who gives lower scores in 
general. This can have the effect of automatically also reducing the 
number of times such a person appears on other users' lists, in order to 
improve the balance. Another possible variation is for example to 
automatically limit at least temporarily the number of times the user can 
appear on other users' lists if his/her number of appearances in other lists 
has gone beyond a certain excess limit defined by the program 
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(preferably in terms of percentages, since the absolute numbers change as 
the database grows). In addition to this, preferably if a user's 
compatibility scores are generally low beyond a certain criterion, 
preferably the system can report to the user (for example automatically 
or upon the user's request after displaying this option) the list of 
questions that most contributed to the problem (for example the 10 
questions that most lower his scores with other people, or all the 
questions that contributed more than a certain factor to lowering the 
scores). This can be done for example by letting the matching program 
that runs on the server keep statistics for each user while running him/her 
against the potential dates, so that the statistics track the questions that 
are most problematic. Another possible variation is to run this statistical 
check only upon request and/or only on a subset sample of potential dates 
in order not to slow down the normal matching process when running the 
search on all potential dates. Another possible variation is for example to 
give the user also the option of choosing sorting by 1-way compatibility 
scores, and in that case preferably the user will get someone only if the 
opposite 1-way compatibility score is above a certain minimum, 
preferably a minimum set by the system and not by the user. (In other 
words you can request a sorting by how much the mate fits your 
expectations, but you will only be allowed to get mates whose 
expectations you also fit to a certain minimum). Preferably in this case 
the search results list shows also the reverse compatibility for each date. 
Of course these options can be used also in normal computer-dating 
systems. As mentioned above, preferably the user has also the option to 
request just a search by a list of traits, which is in other words a 1-way 
compatibility but typically on a small number of traits and without 
necessarily checking the opposite 1-way score, but in this case preferably 
the system can for example create various limitations such as for example 
persons who don't fill the questionnaire completely (or at least a minimal 
subset of required questions) cannot participate at all in searches by 
others, etc., or for example not giving the person's phone, etc., in order to 
reduce the chance for harassment if the search ignores the reverse 
compatibility. So if the questionnaire has for example about 150 
questions, the users can have a very systematic and serious compatibility 
search, but also experiment with instant searches especially when first 
trying out the system, by filling just the Wanted and the Importance in 
the few questions that most interest him/her, and thus start getting results 
already from the first minutes. So for example within minutes after 
entering the system for the first time, the user can search for example for 
all the blondes with high IQ and a big bust that are either currently online 
or not. Allowing such huge flexibility is very important because each 
persons can want very different things so a very large number of 
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questions to choose from is preferably given to the user, eventhough the 
user might choose for example just 3-10 questions to start with, but these 
are the few questions most important to him/her. (When choosing this 
option after the user has already filled the full questionnaire, preferably 
these requested traits are used instead of his preferences as marked for 
the full questionnaire, and his self data from the questionnaire can 
preferably either be taken into consideration or not, or taken into 
consideration at least partially, depending on the type of search or other 
consideartions). Another possible variation is to allow any two users of 
the system to check the exact compatibility between them, for example 
by entering their two unique Id numbers and thus get normal 
compatibility scores or for example an even more detailed analysis. Of 
course, various combinations of the above variations are also possible. 

6. Preferably, if the user requested a search also on people who are not 
currently Online, those that are Online appear in the list of results with a 
preferably easily visible mark, such as for example a different color 
indication and/or text size and/or shape and/or special icon, or for 
example two or more separate lists are generated (or one list divided into 
two or more parts), one with people currently online and one or more 
with people not currently online. Within each list or part of the list 
preferably the results are still ordered by descending compatibility score. 
Preferably near each person in the list of people not currently online there 
is also additional data such as when they were last online and/or how 
often they are usually online (such as for example how many hours on 
average per week or per day). Another possible variation is that the list of 
people who are not currently online can be further divided for example 
into smaller parts, so that for example people who were online in the last 
week appear in a section before people who haven't been online for 
example for more than a month, etc. Within each section preferably the 
sorting is again based on descending, preferably reciprocal, compatibility 
score. Preferably the size of each section can be determined automatically 
for example both by the compatibility score and by the recency. Another 
possible variation is that there are no separate sections according to 
recency, but the compatibility score itself and/or the sorting takes into 
account to a certain degree also the recency, for example according to a 
weight assigned for the recency factor, determined either by the user or 
by the system or both. Of course various combinations of these and other 
options are also possible. Of course many of the options mentioned here 
and in other clauses can also be used in normal computer-dating systems. 
An example of the way the results can look like is shown in Fig. 9. 
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7. Preferably the client program can receive automatic updates from the 
server, so that for example if questions (or options within questions) were 
added or deleted or changed in the compatibility questionnaire, it will be 
updated when the user is online with the client program. This is 
important, since unlike normal dating services on the Internet, where the 
questionnaire is typically on the server, in this case, for efficiency the 
questionnaire can be in the client itself, which also enables filling or 
correcting the questionnaire also when you are offline. Another possible 
variation is that the client program retrieves again a new updated copy of 
the questionnaire when the user goes online. Preferably the client 
program can also be itself updated automatically when needed, for 
example by sending automatically new modules to all the users in the IM 
network. This feature if it had existed in advance could for example be 
used to add the dating option to all the ICQ users 'in the world almost 
instantly (or for example to add additional features to it later), without 
waiting for them to go and download a new version of the client program. 
This is very important, since even if users are informed about a great set 
of new features, it typically takes a long time till they go and actually 
download it, and the lag in updating causes incompatibilities between 
users who have already downloaded the new version and users that 
didn't. It is also much more efficient in terms of bandwidth. (However, 
for reasons of security, when this automatic update occurs, preferably the 
user is informed about it by the system and asked for confirmation). 

8. Preferably, If the user is accessing the system from a client program on a 
different computer then preferably after giving an Id and password, the 
client program can get his/her questionnaire data and a copy of his/her 
contactee list from the server, so he/she can still work normally in the 
instant messaging network. However, this means that a copy of each 
user's contactee list is preferably kept also on the server. 

9. Many of these concepts can also be similarly implemented in cellular 
phone networks, and especially in networks where the phones are 
constantly connected and there is high bandwidth, such as for example in 
the 3G (3 rd Generation) cellular networks. In such networks, in addition 
to the normal ability to send the person an e-mail or an instant message, 
preferably the user can also generate for example an SMS message, or 
generate a phone-call right from the instant-messaging client. However, 
in case some people don't like to give their phone in the questionnaire for 
example for fear of harassment, preferably the system applies an optional 
"phone proxy" or "phone escrew service", which means that the user has 
an option to mark his/her phone as protected, and when someone gets 
his/her phone on the list, that someone can call the user for example 
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through a special visible code but the code does not contain the real 
number and the call has to go through the proxy. The call itself can be 
done for example by direct activation though the client program (if it is 
done for example from a cellular phone connected to the Internet, or from 
a computer with a microphone and sound card), or for example through 
phoning a special number and then clicking the code, and the server there 
automatically routes the call to the real number. This way various 
protections can be implemented, such as for example allowing only a few 
first calls through the code and if the caller does not get from the user 
his/her real phone number by then, he/she can no longer use the code, 
thus automatically preventing harassments. The code can also be for 
example uniquely generated for each person who conducted the search, 
so that the code cannot be used by someone else. Also, since the code can 
preferably be changed very easily, the user can preferably also request to 
change it immediately if harassed by someone, so that someone can't use 
it anymore even if the use limit hasn't been reached yet. Preferably this 
can also be used for example to enforce normal calling times and/or 
preferred calling times specified by the user, so the system preferably 
uses the information about country from the questionnaire and/or the time 
data from the system on each user's computer or cellular phone, and 
using an updated table of time zones, preferably when someone is calling 
through the code, the system makes sure that the call will not be for 
example in the night hours of the person being called. Another possible 
variation is that even without a code, simply clicking for example on a 
phoning option near the displayed date can immediately connect the user 
to that person without disclosing at this stage the number itself. This has 
the further advantage that this clicking option is available only to the 
user, so there is no code that can be transferred to others. Of course, such 
a "Phone proxy" system can be used also in other Online computer dating 
services that want to allow the user to get a list of dates which can all be 
reached immediately by phone, so those that don't v/ant to give the phone 
can use the "protected phone" option. Of course, various combinations of 
the above variations are also possible. 

10. Another problem in such constantly connected cellular networks, and 
also for example in other constant Internet connections, such as through 
cable TV companies or through ADSL, a new definition is needed about 
what it means to be "online", otherwise everyone on those networks can 
be defined as being online all the time (especially if the Instant 
messaging client is configured to connect automatically when starting an 
Internet connection). Therefore, at least in such networks preferably the 
user is considered to be online for example only if he has initiated or 
responded to any action related to the Instant messaging client for 



19/07/02 Yaron Mayer 



18/53 



example in the last hour (or any other reasonable time) and is considered 
to be off-line for example if he hasn't typed anything on the computer for 
a certain time, etc. This means of course that the static and/or dynamic 
database is updated also according to these activity rules and not only 
when a user activates or deactivates the client or the connection. Another 
possible variation is to use these or similar rules also in any type of 
connection, as explained also in the definition of "Online" in the 
definition section. 

11. In cellular networks preferably the system contains also additional 
features, such as being able to get a special indication if someone is very 
near to the user, for example within a certain radius. This can be 
accomplished for example by using info from the cellular company's 
cells, or by using this info directly from the phones, for example when 
they become GPS enabled. This way the user can know for example that 
some compatible date is very close to him/her (for example by a special 
mark in his list of search results and/or in his contactee list). Another 
possible variation is for example that if the user sees someone that he/she 
likes and both have cellular phones and are members of the system, then 
preferably a certain optical or wireless signal generated by the phones 
themselves can tell the user through the status if the person next to 
him/her is available, and preferably the two phones can exchange Id's or 
numbers automatically and/or the questionnaire data directly and thus the 
client program can immediately run a check (preferably through the 
server) to see how compatible the two persons are. Preferably this is done 
by a short range wireless technology, such as Bluetooth, since Bluetooth 
technology will probably be standard on most cellular phones within the 
next few years, but it can also be any other short range wireless 
technology that is or will be used in the future, such as for example 
UWB, which can easily compete with Bluetooth. Another possible 
variation is that the client program on each or at« least on one of the 
phones/cellular devices can run the matching between the user and the 
potential dates in the immediate area without the need to access the 
server for this, for example by running a local, preferably limited version 
of the matching program and limiting the check to the one or more 
relevant persons around. Therefore, this feature can be used also 
independently of the IM network and/or of the online dating service, for 
example by simply letting cellular phones that are close to each other and 
are marked by their user with the status "available for dating" - exchange 
data and check automatically compatibility and alert the user anytime 
he/she is close to someone available for dating and compatible. A more 
limited implementation of this that does not even need a real matching 
program is for example to use this method just to let the user know that 
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someone next to him/her is available for dating, or use it for example 
with a minimum amount of data, such as for example age, sex, education, 
etc. If the match is sufficient, then preferably for example the user or 
each of the matching persons gets at least a few minimal details about the 
other person's appearance (such as for example Appearance, Height, 
Body build, Hair length, Hair color, Hair shape, etc., and/or a picture, if 
available, or "approximate image" if available, as explained below in 
clause 16, if no real picture is available) in order to be able to try and 
match this with what he/she sees around, and the other person's phone 
number (or "proxy number", as explained above, and/or an option to 
click for example on a phone icon near the date's data and be connected 
immediately), and/or be able to enter for example immediate textual chat 
with the other person. This can be useful for example at a university, on a 
bus, on a train, in shopping malls, etc. Another possible variation is that 
the cellular phones (or for example palm or other relevant cellular or 
wireless devices, as explained in the definitions) are able to exchange 
various queries between them. For example each user can mark that out 
of the large number of questions to choose from there are for example 5 
questions which he/she would like to know in advance: for example, 
apart from is the other person available for dating, what is his/her level of 
education, what is his/her main area of work or study, etc. Preferably the 
user can also send the query with additional specifications in order to 
increase the chance that the reply will come from the right person. For 
example in a bus or train or university cafeteria or library there can be 
dozens or even hundreds of people within range. So if for example it is a 
blonde girl that looks a certain age, preferably the user can ask for 
example that only the devices of blonde girls that are available for dating 
and within a certain age limits reply. The query is then preferably 
transmitted by the bluetooth (or other short range communication) to all 
the devices in the vicinity that are in range, and each device checks if its 
user is marked available for dating, and then if he/she fits the definitions, 
before broadcasting the reply to the question described above (such as is 
the person available, what is his/her education, what is his/her field of 
study or work, etc.). Preferably there is a different answer if the person is 
not available than if he/she is not a member of the system, otherwise a 
lack of reply could mean ambiguously both of these possibilities. 
Another possible variation is that the phone (or a preferably small and 
non-conspicuous add-on coupled to the phone) enables the user to point 
his/her device directly at the direction of the person that caught his/her 
eye, which preferably transmits some Id code and/or the phone number of 
the user who points it, and preferably sensors on that device of the person 
that was pointed to can find out that someone pointed the device and 
reply to the query directly with its own Id and/or phone number, etc. This 
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pointing device can be based for example on infrared or on a directional 
short range wireless antenna. (This can work also on other devices even 
without the cellular network, such as for example palm devices that are 
bluetooth enabled even if they are not connected to the cellular network, 
or special gadgets for dating). However this is less desirable, since most 
people will be embarrassed to buy a special device for that and/or 
embarrassed to be seen pointing the phone at someone. Another possible 
variation is to implement it on the level of cells or groups of cells, so that 
the cellular phones know that they are close to each other for example by 
getting the information from the cellular company's cells. Another 
possible variation is to run the matching normally, but when dates are 
found that according to the info from the cells and/or for example from 
the GPS and/or for example from the bluetooth indication (or other short 
range communication technology) are also very close to the user, these 
dates are preferably for example marked with a special conspicuous sign 
(for example in the search results list and/or or in the contactee list) 
and/or moved to a special category on top of the list of date search results 
and/or in the contactee list, or their score for match on area in increased 
by a certain factor and simply incorporated in the total compatibility 
score. In this version, preferably dates that are close for example by 
blutooth indication are given even a more emphasized mark or moved 
higher to the top than dates who are only close by info from the cells. 
Since for some users the level of compatibility is much more important as 
long as the date is still within a reasonable area, while for others the fact 
that someone is now very close to them might be more important, 
preferably the user can easily experiment with increasing and reducing 
the weight given to the immediate vicinity factor. Also, for example 
people looking for pen-pals will probably put much less weight on the 
area. Another possible variation is that the system allows the user also to 
request separate search results lists (and/or contactee lists) according to 
area or marking for closer people - also more generally, such as for 
example putting all the people from the same country or state or town in 
a separate category. Another possible variation is that if the server or 
servers become for example too overloaded because of too many users 
using the system, preferably different servers are used for different areas 
and date searches are for example limited in the size of areas that can be 
requested. Of course, various combinations of the above variations are 
also possible. 

12.Preferably if someone hasn't entered the system for a certain time period, 
such as a for example a few months (and/or if someone else fills a for 
example a "freeze form" or some other form of report about that person, 
reporting that the person said that it is no longer relevant), the server can 
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preferably generate an automatic message to him/her (for example 
through e-mail or instant message) to ask for example if he/she is still 
interested in compatible dates, and if the person confirms this, or if no 
reply comes back for example after a certain period or preferably after 
sending more reminders, the person is preferably automatically "frozen" 
(so that people no longer receive him/her in the searches) until there is 
another indication (for example if he/she enters the system, or performs a 
new search, or updates the data, etc.). Preferably, the freeze form 
contains also the reason (such as for example the person found someone 
through the service, found someone elsewhere, found someone trough the 
service and got married, found someone not trough the service and got 
married, etc.). Another possible variation is that the system ignores the 
"freeze form" if the user has been active very recently or is currently 
Online, and especially if he/she performed a date-related activity such as 
conducting a date-search recently. Another possible variation is that the 
system does not ignore the freeze form if the reason is more significant, 
such as for example the person got married according to the report. By 
using this feature the weight given to the recency data can be 
significantly reduced since this can significantly decrease the chance that 
the potential dates found will be no longer relevant, even if their data is 
older. 

13. In one of the possible embodiments, preferably when the matching is 
done, the matching program (which is preferably on the server or 
servers), can take into account at least in some questions (preferably 
except in questions where the user marked the question as "necessary") 
also the distance between what was requested and what was found. For 
example, if the user wanted a date that is only "Highly above average" in 
appearance and an otherwise highly compatible date rated herself as just 
"above average" in appearance", the number of points taken down 
because of this mismatch can be lower than if the date rated herself as 
"average". This is preferably implemented especially for example in 
ordinal scale questions which are also subjective in nature, since in such 
questions the replies both in self description and in the requested ideal 
date should preferably be taken with caution. Preferably, this distance 
function can in some cases take into account also the direction of 
difference, and regard the distance differently depending on this 
direction. For example, if the user wants someone who only has a post 
secondary education and the date has a B.A., the "damage" to the user 
should be much smaller than if the user only has highschool education. A 
more extreme variation of this that the system automatically 
complements the wanted scale upwards at least in some of these cases 
where it clearly makes no sense to ask for something bad and not mark 
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also better options, however this is preferably done with caution since my 
own research has shown that it many cases users still insist on the 
"unreasonable reply" even when confronted with it. However this more 
extreme variation is not needed when the users fill the questionnaire 
online, since the filling program itself can warn them about such illogic 
request, and if they still insist that so be it. 

14. When matching by area, some computer dating systems today match by 
letting the user mark his/her own area (for example town, state and 
country), and also a list of areas from which the potential dates can be, 
and some match instead for example by zip code. However, using the zip 
code alone is problematic because zip codes depend on many things and 
do not necessarily translate to actual distances. For example in Australia 
a small difference in zip numbers can represent a huge distance, 
compared for example to Honk Kong where it can represent much 
smaller distances. A better solution is to use matching by selected areas, 
and use other info such as for example the absolute difference from 
subtracting two zip numbers only as a supplement. So preferably the 
difference in zip codes is used only when the date is in one of the 
requested areas. Another possible variation is to take the zip code into 
account when the date is outside the requested area., in a way similar to 
the distance function described in clause 13 above. Anyway, this can 
work only within countries since the zip system can be different between 
countries. Another possible variation is to use for example the first few 
digits of the phone numbers (or the absolute difference (subtraction) 
between the numbers) instead or in addition to zip data. However this is 
problematic since it does not help for example if people give a cellular 
phone instead of their stationary phone number. Preferably this is used in 
addition to the variation of using proximity data described in clause 11. 
Another possible variation is to use directly absolute Geographical 
location information, such as for example GPS coordinates, for example 
directly from each user's IP address, since this Geographical Location 
will be probably available in the next generation Internet. This is much 
more reliable and exact then zip code. Another possible variation is to 
still use this together with the areas selected by the users. Of course 
various combinations of the above variations are also possible. 

15. Preferably the user can also request from the system to notify him/her 
automatically whenever there is a new potential date that entered the 
system and has a higher compatibility with him/her than a certain 
criterion (such as for example higher than the lowest compatibility score 
in his/her current contactee list, or higher than an absolute minimal score 
defined by the user), or fulfills a certain condition, for example, all 
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blondes with big bust and high IQ. Another possible variation is that this 
is done for example automatically by default unless the user requests 
otherwise. This is better than the state of the art, where the user gets a list 
only at certain times (such as for example once a month or, when he/she 
himself initiates a search). This can be applied for example when the new 
person submits his/her data for the first time to the system or performs a 
compatibility search for the first time, and preferably the user can ask 
either to be notified for example whenever such a new person exists in 
the static database, (if there is a static database), or only when that user is 
also Online (Of course when submitting the questionnaire or performing 
the search the new person is by definition Online, but the user that 
wished to be notified might be for example offline at that time and when 
he/she comes back Online the new person might be offline already). This 
can be done for example by keeping pending search requests (preferably 
only one search-request or up to a few pending search requests permitted 
per person) and/or keeping the minimum criterion for that person on 
his/her record on the server (for example the lowest score on the list that 
he/she got so far and/or the lowest score on his contactee list so far), and 
for example when the new person sends his/her data for the first time or 
requests a search or changes the data (but for efficiency reason most 
preferably this is done only or mainly when the new user requests a 
search), a reciprocal search is performed on all the potential mates in the 
system, and while checking the new person's data against each relevant 
potential mate in the system, the server preferably also checks if a 
condition has been fulfilled that requires sending the appropriate 
notification or update to the person against which the new person's data 
is being checked. This may sound a bit inefficient but preferably it has 
only a relatively small effect on the search speed, since various 
optimizations can be performed anyway such as for example stopping the 
comparison with a given person immediately for example if the area 
doesn't fit or the age doesn't fit. Preferably the user can also choose for 
example if he/she wants to be notified by an e-mail and/or instant 
message and/or by automatically having the new persons be inserted into 
his/her list of contactees (This choice can be made for example in 
general, or depending on the case, so that for example the user requests 
that someone be added automatically into his/her contactee list only in 
cases of especially high matching). Preferably the new person also has 
the choice in advance if he/she wants to be inserted automatically into the 
contactee lists of relevant people or at least for example into the 
contactee lists of the persons on top of his/her list of date-search results. 
This saves a lot of time and increases the chance for instant connection, 
especially if the new person prefers for example that the other dates 
contact him/her (females for example tend more than males to prefer to 
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wait for someone to contact them). When the user is a member through 
cellular phone and not currently Online, another possible variation is to 
notify the user also for example preferably by sending an automatic ring 
signal to the phone and then displaying the message. Preferably by 
clicking on an icon or option near the user's data the user can than 
automatically enter for example chat mode with the person or initiate an 
automatic call to the person (without knowing the actual number at this 
stage). This can be used also for example whenever someone highly 
compatible enters within Bluetooth range from him/her or is close 
according to the information from the cells, or for example from the GPS, 
and then preferably the user is also given data that can help him/her 
locate the person for example by showing the appearance data that are 
available. Of course, various combinations of the above variations are 
also possible. 

16. Since practice shows that most people in computer dating services, 
including Online services, don't like to send their pictures but prefer to 
search dates that have pictures, preferably the system allows users to use 
a systematic data pool of pictures (which can be for example a taxonomy 
or hierarchy), preferably real photographs (for example hundreds of 
pictures of male faces, hundreds of pictures of female faces, and similar 
separate sets for body shapes) and to choose at least the face that is most 
similar to the way they look and preferably also the body shape that is 
most similar to the way they look, and preferably also mark similarly the 
kinds of appearances they would most like in their ideal date (for 
example by marking the pictures that they most like, preferably with the 
ability to indicate the level of liking on a scale). Preferably there are more 
faces to choose from than body shapes, since there is much more possible 
variation in faces. Another possible variation is to use preferably 
carefully drawn images, which makes it easier to control more 
systematically various variables (or for example some photos and some 
drawings, etc.). Another possible variation is to make the choices (for 
example both for self description and for description of the ideal date) 
more modular than just body and faces, thus allowing the users to create 
more combinations. This is also important because it is very difficult to 
properly cover appearance, which is wholistic, by a few analytic 
questions. Preferably when this additional info is available it is used for 
the scoring of compatibility in appearance in addition to the normal 
textual question about appearance. Preferably when there is no direct 
match between marked self image and marked preferences in these 
images, the system takes into account a also the distance between the 
preferred and the actual image, based on the systematic classification of 
the images according to various variables. When a potential date's data is 
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displayed, and when no real picture of the date is available, preferably 
this "approximate image" is displayed instead. This has the additional 
advantage of saving bandwidth and saving space and load on the server, 
because for approximate images it is sufficient to transfer just some 
numerical codes. Preferably these pictures or images are small and are 
downloaded automatically as part of the client, so that viewing them does 
not overload the server. (Preferably they can also be automatically 
updated sometimes by the server when needed, like the other updates 
described in clause 7). For efficiency reasons, preferably when letting the 
user mark choices many images are displayed on the screen together, as 
long as they don't become too small to discern the important details. 
Another possible variation is that the user is preferably asked to make 
choices in a tree-like manner - for example choose first between a 
number of images and then refine the choices based on the previous 
choices. When the choice is made for self description preferably the user 
can choose only one answer on each step in the tree, and when the 
choices are made for the desired date preferably the user can mark 
multiple options at least in some of the stages. (Preferably at least the top 
of the decision making tree may contain textual descriptions and/or 
explanations instead or in addition to images). Another possible variation 
is that preferably the user first fills the textual questions about appearance 
and then the system displays the graphic choices already based on the 
textual information about the self description and about the desired date. 
This narrows down the choices that have to be made and the number of 
images that actually need to be displayed and thus increases the 
efficiency. This way even if thousands of images are available to choose 
from, the choices can still be made very quickly and very efficiently. 
Another possible variation is that this is used even with users that do send 
a photo, in addition to the photo, because of the above described 
advantages in comparison to just using photos. Of course, various 
combinations of the above variations are also possible. 

1 7. Another problem, that exists both in IM networks and in Online dating 
service, is that many times the same user enters the system under more 
than one identity, for example because he/she forgot his/her login and/or 
password, or because he/she wants to get again a free bonus that is 
offered only to new users, or because he/she wants to experiment with a 
few different identities, or other reasons. However, this can create a 
number of problems, such as for example making jt hard to know how 
many real people are actually in the system, the possibility that a user 
will get someone on the list or lists of compatible dates more than once, 
with different compatibility scores each time, and making it hard to 
determine if a user is really new or not in systems where for example a 
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user gets one free list and then has to pay for the next, or for example if 
the method of "proxy phone" is used, since by using different identities 
users can cheat the number of limitations. Therefore, preferably the 
system uses various heuristics in order to try to automatically catch 
suspect duplicates: For example, if the e-mail starts with the same or a 
very similar name on the left side of the "@" and/or if the name is similar 
and the birth date is the same or very similar, preferably the system 
checks if other data are also similar (such as for example area and other 
important background data, or some numerical function of the general 
similarity between the suspected duplicate profiles), and then 
automatically decides if the data is similar enough to decide that it is the 
same person. If it is, then the system preferably automatically uses the 
new data as an update of the older data and preferably also notifies the 
user about it. If the system is less sure, then preferably it asks the user if 
he/she is indeed the same person and/or reports it to a log for human 
decision and/or warns the user for example that various sanctions will be 
taken against people who deliberately try to mislead the system. 

Another possible embodiment of this invention is to use at least some of the 
above features in a normal Internet computer dating service, preferably with the 
additional requirement that each user must also supply a phone number 
(preferably with the option of requesting "protected phone" as described above) 
and preferably also an instant messaging id if available. This is preferably done 
together with reciprocal compatibility search, since people are more willing to 
give the phone if they know that the people that get them also fulfill their own 
expectations. The feature of automatic notification (described in clause 15 
above) in this case (without instant messaging and contactee lists as an inherent 
part of the system) is preferably done for example by seeding the person that 
requested the notification an automatic e-mail message about it, or SMS, (or 
for example an automatically generated phone-call, if he/she pays for it), 
preferably including the phone number (or proxy-phone number as a code or a 
link without code) of the new person (preferably in addition to the new person's 
e-mail, and preferably also IM number, if available), so that the person 
receiving the notification can also contact the new person immediately. This is 
in contrast to the state of the art, in which users are updated only on a periodic 
basis or when they perform a search. Another possible variation is that, for 
users that gave also an IM id number, the system tries to find out if they are 
currently Online for example through an element that contacts the relevant 
server, and if so, when showing a potential date's data on a dating search results 
list, the system preferably shows also his/her IM id number, the IM network 
that it belongs to, and an indication if he/she is Online, so that the user can 
contact him/her through the appropriate IM client program. Another possible 
variation is that being Online can be defined by at least one of the following 
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two conditions: A user has logged into the system with his/her user name and 
password not longer than a certain time ago, b. A user has performed at least 1 
activity in the system not longer than a certain time ago. Another possible 
variation is that the system allows users to send to persons who are currently 
online according to the above definition instant messages for example by 
displaying a preferably visibly conspicuous messages to the person for example 
the next time he/she tries to access pages on the system (for example any page, 
or most pages or the menu) (this can be done for example by generating a page 
on the fly when the system recognizes by browser cookies that this is the person 
for whom the message is intended) and preferably one of the options on this 
generated page is to press a link that enables the users to enter a chat channel. 
Another possible variation is that some or all of the pages on the dating site 
have an automatic refresh instruction (for example once every minute or every 
few minutes, for example through an html tag or through Javascipt or ActiveX, 
if the browser supports it) and the user simply has to leave at least one window 
of the browser open on the site (and it is preferably recommended to do so in 
the instructions for users on the site) and the user can for example go on sliding 
in other windows, and when there is a notification for him/her, then it is 
included automatically in the next refresh, preferably with the addition of an 
audible sound that can get the user's attention. If it is by Javascript or ActiveX, 
preferably the Javascript or ActiveX can also check for example if the user 
continues to actively use the browser (in order to be able to apply more 
efficiently the activity rules to check if the user is still Online), and when 
requesting the refresh the browser can for example transfer an additional 
parameter to the requested url that represents the Online status of the user. If it 
is ActiveX, this can be even more comprehensive, because the ActiveX can 
preferably know for example if the user typed or clicked anything at all and not 
just used the browser. This has the advantage that no special client program is 
needed in addition to the browser. Of course, adding additional IM features to 
an online computer- dating service in addition to this can make it equivalent to 
adding Computer Dating features to IM networks. Preferably, this method can 
also be used as an additional option for the automatic notification. Of course, 
various combinations of these variations can also be used. 

Fig. 1 shows a preferable way in which the user fills the questionnaire as a 
plug-in or add-on within an instant-messaging client program. When the user 
activates the client (11), the system first checks if the user has already been 
registered in the system and, if not, gives him/her a new unique user id, and/or 
the system can also use for example the id that the user has in the network in 
which he/she is a member together with a code of the network. (This check can 
be done either by checking locally on the user's computer or by checking on 
our server(s) on the Internet) (12). If the user hasn't filled the questionnaire 
already, he is asked to fill it, including preferably his self description, 
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description of the ideal date, and the importance for each question (13). Then, if 
the user has made changes or has filled the questionnaire for the first time, the 
user's data is saved, preferably both on the user's computer and on our 
servers(s) on the Internet in a static database of all users who filled the 
questionnaire or in a dynamic database of users currently online (14). After this, 
the user continues to work with the instant messaging client (15). 

Fig. 2 shows a preferable way in which the user fills the questionnaire as a 
standalone application or as part of custom-made instant messaging client. First 
the system checks if the user has already been registered in the system and, if 
not, gives him/her a new unique user id, and or the system can also use for 
example the id that the user has in the network in which he/she is a member 
together with a code of the network. (This check can be done either by checking 
locally on the user's computer or by checking on our server(s) on the Internet) 
(21). If the user hasn't filled the questionnaire already, he is asked to fill it, 
including preferably his self description, description of the ideal date, and the 
importance for each question (22). Then if the user has made changed or has 
filled the questionnaire for the first time, the user's data is saved, preferably 
both on the user's computer and on our servers(s) on the Internet in a static 
database of all users who filled the questionnaire or in a dynamic database of 
users currently online (23). After this, the user either activates the instant 
messaging client program which is coupled to the search plug-in or add-on (if 
the standalone filling application works in conjunction with the existing main 
instant messaging networks) or continues to work with the standalone' s own 
instant messaging client (if it is part of our own instant messaging client) (24). 

Fig. 3 shows a preferable way in which the dynamic database of users that are 
currently Online works. As soon as the user opens the Internet connection and 
activates the instant messaging client (which is either our own client program or 
the client program of one of the common instant messaging networks with our 
custom-made plug-in or plug-ins or add-on or add-ons), preferably a message is 
sent to the dynamic database server(s) containing the user's filled compatibility 
questionnaire data (31). Then our client or the plug-in or add-on coupled to the 
client keeps sending at short intervals a short message to one of our servers 
containing the user's unique id so that the system can tell if the user is still 
logged-in (preferably these short messages are sent either to the Database server 
itself or to another server, which will in turn notify the database server if the 
messages stop coming) (32). When the user requests an instant dating search 
(For example with his profile in a 2-way compatibility search or as a 1-way 
search or search for a small group of qualities, for example - find all the 
blondes with highest IQ who are currently logged in, or find them for example 
only if the reciprocal compatibility score with them is above a certain percent; 
Other search options can be for to example find only dates with a minimum 



19/07/02 Yaron Mayer 



29/53 



compatibility score requested by the user, but preferably the user cannot request 
a minimal score lower than a certain minimum required by the system as the 
minimal acceptable compatibility score), the client sends the appropriate 
request to the dynamic database (33). The dynamic database will make the 
search accordingly and send back the list of most compatible dates that are 
currently connected, preferably including various details about them according 
to the type of search. The user may also add any of them to his/her contactee list 
and can be notified immediately when they are Online again (34) in a similar 
way to the description of 44. When the short messages from the client cease 
reaching the appropriate server, indicating that the user is no longer connected, 
his data is removed from the dynamic database (35). 

Fig. 4 shows a preferable way in which the static database of users that filled 
the compatibility questionnaire works. After the user finishes filling the 
questionnaire or makes changes to it, his or her data (including also his name, e- 
mail and unique user Id) is transferred to the static DB (41) and is preferably 
saved also on the user's computer. As soon as the user activates the instant 
messaging client, short messages are again sent to the appropriate server as in 
Figure 3, and the static database also preferably sets a logged-on mark in the 
Ll record of each user that is currently logged-in on the Internet (This mark may 

01 be also set for example at a separate file or index or pointer in addition or 

instead, and held for example in RAM memory for maximum access speed, or 
on the disk, or both) (42). When the user requests a dating search (again, for 
ll example 2-way compatibility or 1 way search or search for just certain 

© attributes), most preferably he/she may also choose if he/she wants to search for 

all compatible dates or only those that are currently Online. (If the user wants to 
search only for people who are currently online, preferably he has the option of 
choosing for example a maximum time that elapsed since someone was online 
or the minimum average frequency that someone is online) (43). The list of 
most compatible dates (again, most preferably, with various details) can be 
added to the user's list of contactees in the instant messaging client (if it's our 
own client or the contactee is a member of the same network) or to a special list 
maintained by the plug-in or add-on (if it is a plug-in or add-on coupled to one 
of the common instant messaging clients). Preferably, the user has a choice of 
marking which of these compatible dates to add to his contactee list or which of 
them to remove. (44). If any of these chosen compatible dates becomes Online, 
the user is immediately notified about it (45). When a user is no longer online, 
his/her on-line mark or marks are set again to off (46). 

Fig. 5 shows a preferable way in which the compatible-date search application 
works as a plug-in or add-on within an instant messaging client. When the user 
wants to search for new compatible people, he/she chooses within the plug- in or 
add-on for example if he/she wants to execute a 2-way compatibility search or 
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just search for people with certain qualities (and also if to search only for 
people currently Online, if it is a static DB) (51). The plug-in or add-on then 
transfers the search request to the appropriate DB server (Which can be for 
example static, or dynamic, or both) and then displays the results to the user as 
explained in fig 3 and 4) (52). 

Fig. 6 shows a preferable way in which the compatible-date search application 
works within a custom-made instant messaging client (in other words - our own 
client). When the user wants to search for new compatible people, he/she 
chooses for example if he/she wants to execute a 2-way compatibility search or 
just search for people with certain qualities (and also if to search only for 
people currently Online, if it is a static DB) (61). The client then transfers the 
search request to the appropriate DB server (Which can be for example static, 
or dynamic, or both) and then displays the results to the user as explained in fig 
3 and 4) (62). This custom-made client can be either a stand-alone application, 
or work as a plug-in or add-on within another Internet application such as one 
of the big browsers (such as Netscape or Microsoft Internet Explorer), or be an 
integral part of it. 

Fig. 7 is a schematic diagram of a preferable way that the add-on can for 
example let the client or part of the client act as if it is communicating with 
another client of the same network or with its server, but translate the 
communication to another protocol and/or redirect it to the other network. 
When the user's client program is trying communicate in its normal protocol, 
for example ICQ, with the normal interface of its chat windows (71), if the 
plug-in or add-on sees that the communication is actually intended for or 
coming from a client of a different network, for example MSN (72), it 
preferably steps-in and converts between protocols as needed (73). If it's an 
outgoing communication the add-on or plug-in preferably redirects the output to 
the appropriate server or client of the other network as needed. If it is an 
incoming communication it preferably translates it into the protocol that the 
client program expects to see and makes the client think that this 
communication came from its own network. In order to enable this, preferably 
all the contactees that are not really members of the client program's IM 
network are specially marked by the plug-in or add-on, So that it can intervene 
when the user's client program is trying to communicate with them. 

Fig. 8 is an example of a preferable way that the extended contactee list can 
look like. In the example shown the order is to show first contactees that are 
available for dating, then friends or other contactees not related to dating 
(marked with "N/A" = Not Applicable), and then people who were found in the 
context of date searching but are now no more interested or available for dating. 
In this example this group is preferably last since the user is probably least 
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likely to want to contact them. Inside each group the order can be for example 
alphabetic and/or based on the most recent activity and/or on putting the 
persons with the longest contact history with the user on top, or any 
combinations of this, as explained in the reference to this in Fig. la. ("comm." 
stands for communications with the user). When someone is not available 
preferably he/she changes his/her status on his/her client, which then preferably 
propagates automatically to update all the other contactee lists where that 
person is listed. This is like having a computer dating output list which is 
updated in real time (or when the user is next Online) whenever there is any 
change in the status of the persons on the list. In this example "*F" means 
found someone through the service, "*E" means found someone elsewhere, 
"*TF" and "*TE" mean this new status is only temporary, "*FM means found 
someone trough the service and got married", "*EM means found someone not 
trough the service and got married", "*T means temporarily unavailable, etc. Of 
course other status options and codes can be used instead or in addition. For 
implementing for example the reporting on most frequent activity hours 
(activity in the IM network), preferably the statistics are gathered for each user 
by his/her own client program and sent to the server, in order to save time and 
not unne cessarily burden the server or servers. Preferably, the various times 
data are displayed in terms of the user's local time zone (for example by taking 
into account the different time zones between the user and the contactee and 
automatically adjusting it). Preferably the compatibility scores (as reported in 
the search results list) with each person in the contactee list is also saved 
automatically when the person is added to the contactee list, so that the user can 
click on or near the contactee in order to get for example a reminder of these 
scores, and or view also the contactee's profile or at least part of it. 

Fig. 9 is an example of a preferable way that the list of most compatible dates 
following a reciprocal compatibility search can look like. Since there are 
preferably a serious number of questions (such as for example 100 or above) for 
enabling really systematic matching, it is impractical to show the full profile of 
the date to the user, and it is also undesired because: A. some questions or types 
of questions (such as in the area of personality for example) are preferably kept 
discrete, otherwise people will not answer them honestly. B. With such a large 
number of questions people have a problem analyzing and integrating all this 
information, so detailed compatibility scores plus a list of most important 
fulfilled expectations can help the user see the picture very efficiently. Another 
possible variation is for example to let the user click on the date in order to get 
his/her profile, but the profile is preferably shown without the questions marked 
as discrete or confidential. Another possible variation is that when the user 
requests to see the date's profile, he/she is shown only the answers the date 
gave on the questions most important to him/her (preferably with the additional 
limitation that in any case this does not include question that are considered 
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discrete or confidential). For this reason preferably in the questionnaire itself 
the questions that are considered discrete and confidential are preferably 
marked differently. (Another possible variation is that the user can also mark 
for example up to a certain amount of questions as confidential while filling the 
questionnaire or correcting it, or can mark questions in certain section as 
confidential if he/she chooses, but this is less desirable since it can make filling 
the questionnaire more cumbersome). This is just an example of a possible way 
of ordering the results. Another possible variation is for example to list the 
Online and Offline users together in descending order of compatibility scores, 
and just add a mark, or indicate for example by different color if they are online 
or offline. For example, dates who are currently online can be marked in a 
bright color, dates who are offline but have recently been online are marked in a 
darker color, and dates who have not been online for example for a few months 
(a limit which preferably can be determined also by the user), are marked for 
example in gray. Of course, more than 3 levels can also be used. This is more 
J useful for people who want to seriously find a date and don't care if he/she is 

l currently online or not, whereas people who prefer for example to chat with a 

compatible date right now will probably prefer the option that lists them 
separately. Therefore, preferably the user can choose which of these options to 
\Z use. Other issues of ordering the results and of search and sorting options were 

W discussed in the reference to this in Fig la above. Another possible variation is 

* m that the user can also save this list for later reference, and if there is change for 

55 example in the availability for dating of any of the persons in the list or for 

h& example in their geographical/physical vicinity, it is preferably updated 

z automatically in a way similar to the way that this status can be updated 

automatically for people in the contactee list, as explained in the reference to 
Figs, la & 8. Another possible variation is that after looking at the list the user 
can for example mark persons whom he/she doesn't want to show up again in 
future searches (this set of marked persons can be saved for example on the 
client or on the server or both). Also, other variations are possible, such as for 
example showing on the results list more concise data on each person that is 
expanded (for example into a separate window) if the user clicks on that person, 
or displaying for example a few separate sets of concise results for example for 
each geographical area that the user requested, etc. Of course various 
combinations of these and other variations are also possible. 

While the invention has been described with respect to a limited number 
of embodiments, it will be appreciated that many variations, modifications, 
expansions and other applications of the invention may be made which are 
included within the scope of the present invention, as would be obvious to 
those skilled in the art. 



